The Highs and Lows of Change Control

C hange control. For me, this vital issue in software project management immediately conjures the image of the famous 1984 Macintosh commercial. Remember that one? Gray drudges standing row upon row, staring with numb compliance at a lecturing bureaucrat , set free by a hero who bursts in and hurls a hammer that breaks the spell of Big Bad Brother. This image depicts my personal struggle with the problem of managing improvements to a product. Although my temperament is that of hammer-throwing hero, my role as quality assurance guy is more like lecturing bureaucrat. Part of me wants to open the flood gates to improvements and better ideas; the other part wants to protect the existing quality of the product by limiting change. Change control is vital. But the forces that make it necessary also make it annoying. We worry about change because a tiny perturbation in the code can create a big failure in the product. But it can also fix a big failure or enable wonderful new capabilities. We worry about change because a single rogue developer could sink the project; yet brilliant ideas also originate in the minds of those rogues, and a burdensome change-control process could effectively discourage them from doing creative work. My ambivalence about this issue is only deepened by the fact that change-control processes are easily corrupted. Change control means risk analysis, and there's no easy or certain way to do that. Coupled with the amazing capacity we humans have for oversimplifying the complex, change control can become mindless resistance to change and an automatic rejection of all risk, regardless of potential reward. Or, just as easily, change control may degenerate into a set of empty rituals that allow any change to be made as long as the rituals are honored. Such a process is less a practical device than a sort of gargoyle meant to scare evil spirits or impress clients. Midway between allowing nothing or everything, change control may also become a political filter where change is resisted unless you're in with the in-crowd, regardless of the situation's merits. At SmartPatents, change control processes are (at least officially) my responsibility. How can I avoid the role of bureaucrat, gargoyle, or political poll-ster? How can I help the process work well? Let me describe the process we've arrived at, then decide for yourself if I deserve the hammer treatment. The only legitimate …